home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13418 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.2 KB
  1. Path: inforamp.net!ts4-03
  2. From: rmorin@inforamp.net (Randy Charles Morin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: Tue, 26 Mar 96 07:48:41 GMT
  6. Organization: MiddleWorld SoftWare
  7. Message-ID: <4j87hg$q74@sam.inforamp.net>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu> <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net> <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net> <314EBD08.43BC@virtus.com> <4io2i7$n9v@sam.inforamp.net> <4isu2t$opo@jan <4j2jot$svj@sam.inforamp.net> <4j4gkq$j6c@janus.pec.co.nz>
  9. NNTP-Posting-Host: ts4-03.tor.inforamp.net
  10. X-Newsreader: News Xpress Version 1.0 Beta #4
  11.  
  12. In article <4j4gkq$j6c@janus.pec.co.nz>,
  13.    JohnM@hypatia.pec.co.nz (John Marshall) wrote:
  14. >Huh?  My post-compilation objects are monolithic applications, and if my
  15. >data types change, they don't know about it until I make the effort to
  16. >type "make" to make a new version.
  17.  
  18. When you think of your post-compilation objects as being applications, 
  19. you have completely ignored the object oriented ideology.  Think about 
  20. sharing objects and I think you will understand.
  21.  
  22. >Oh, so I'm writing a *library*.  And it's shipped to users separately from
  23. >the applications that use it.  Why didn't you say so?
  24.  
  25. I did not say a library.  But that is another example.  We are talking 
  26. about a coding standard for a large corporation.  Their coding standard 
  27. should be able to handle every situation they are presented with.
  28.  
  29. >> If you don't have 
  30. >> inline accessors, then you don't have a problem.  Is this so hard to 
  31. >> understand?
  32. >Well, yes, as usual it is hard to understand, simply because it's not true.
  33. >Inline accessors are only one of the things you have to worry about.
  34.  
  35. Obviously.  So what you are saying is that we shouldn't attempt to
  36. hide data, because it is only one of many things we need to do to 
  37. properly hide data.  Why not implement all of these THINGS?  And to 
  38. accomplish this object oriented goal, you need to use all of these 
  39. THINGS.  Including proper data hiding.
  40.  
  41. >For example, depending on your DLL technology, you may have to be very
  42. >careful about rearranging or adding to the list of externally visible
  43. >functions, for fear of changing entry point offsets.
  44.  
  45. So what you are saying is that if you use ordinal numbering of functions,
  46. then you don't have a problem and you can rearrange and add functions
  47. without fear of changing entry points. 
  48.  
  49. >On the other hand, if one *is* writing a monolithic application, then inline
  50. >accessors are no more harmful than anything else.
  51.  
  52. Agreed.  Inline accessors are a great asset that can be used to 
  53. enhance the performance of some applications.  I never said that you 
  54. should outlaw the use of inline accessors.  I was arging that
  55. arbitrarily mandating that all accessors be inline is wrong.  You
  56. disagreed.  I assume that your entire argument was based on this 
  57. misunderstanding.
  58.  
  59. >It seems to me that what developers need is knowledge of all these
  60. >implications, rather than just blind adherence to some incomplete rule
  61. >like "NEVER use the word inline".
  62.  
  63. Agree.  Again, you are confirming my exact sentiments.
  64.  
  65.  
  66.  
  67. Agrivar
  68.  
  69. aka     Randy Charles Morin
  70.     MiddleWorld SoftWare
  71.     Canada: 1-800-363-3780
  72.     Other:    905-279-2087
  73.